home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 8192 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: news.halcyon.com!usenet
  2. From: normanb@halcyon.com (Norm Bryar)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Bizzare C++ bug...PLEASE CHECK IT OUT
  5. Date: Thu, 15 Feb 1996 17:17:54 GMT
  6. Organization: Northwest Nexus Inc.
  7. Message-ID: <4fvpr1$l27@news.halcyon.com>
  8. References: <4fsns9$8ga3@flute.aix.calpoly.edu>
  9. NNTP-Posting-Host: blv-pm10-ip5.halcyon.com
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. Comments appended with <==
  13.                 --Norm 
  14.  
  15. mporcell@flute.aix.calpoly.edu (Michael Anthony Porcelli) wrote:
  16.  
  17. >Hello all you helpful people.  I was working on a project for school and I
  18. >ran into a super hard-to-find bug.  Well, I found it and the project is
  19. >complete, but *where* the bug occured was what made it so hard to find and I
  20. >*still* don't understand why it occured when it did.  Any input on this
  21. >would be appreciated.  Thanks.  Here it is:
  22.  
  23. >struct A {
  24. >   A(...);
  25. >   ...
  26. >   virtual ostream &Print(void) = 0;   // r1
  27. >   friend ostream &operator<<(ostream &os, const A &a) {return l.Print(os)}
  28. >     //r2
  29. >   ...
  30. >}
  31.  
  32. Cool, I've never seen someone *define*        <==
  33. a utility function within a struct or class    <==
  34. and not have to use scope-resolution        <==
  35. to access it.  Must be 'cause of 'friend.'    <==
  36.  
  37. What does it mean to call I.Print(os)        <==
  38. when the argument is a and A::Print        <==
  39. takes no parameters?                <==
  40.  
  41. In MSVC4, if I defined operator<< as        <==
  42. { return a.Print(os); } and declare Print to    <==
  43. take an ostream parameter, then my        <==
  44. linker would groan "unresolved external."    <==
  45. I'd fix that by defining Print as follows        <==
  46. virtual ostream & Print(ostream & os) = 0    <==
  47. { NULL; }                        <==
  48. Giving a pure-virtual a body is legal and    <==
  49. makes the linker happy, even though        <==
  50. at runtime I'd never expect A::Print() to    <==
  51. get called.                        <==
  52. Could this help?                    <==
  53.  
  54. >struct B : public A {
  55. >   B(...);
  56. >   ...
  57. >}
  58.  
  59. >B::B(...) : A(...), ... {  //r3
  60. >   //              ^
  61. >   // Bug *occurs* here
  62. >   ...
  63. >   os << *this;  //r4
  64. >   // ^^
  65. >   // Bug *is* here
  66. >   ...
  67. >}
  68. >   
  69. >struct C : public B {
  70. >   ...
  71. >   ostream &Print(void) const;  //r5
  72. >   ...
  73. >}
  74. >...
  75. >ostram &C::Print(void) {
  76. >   ...
  77. >}
  78.  
  79. >Well.  I've tried to show in as much detail as I could exactly what was
  80. >going on.  The bug was a compile time bug that produced the message:
  81.  
  82. >Abort Process
  83.  
  84. >Clearly the call to the overloaded operator<< (r2) at r4 will cause a crash
  85. >because it is a call from a base class constructor (B) to a virtual print 
  86. >function (r1) that does not get defined until the derived class C (r5).  The 
  87. >reason that this bug was so darn hard to find is that it occured at r3 and 
  88. >*not* at its location in the code (r4).  I still have absolutely *no* idea
  89. >why this is so.  It is perhaps a compiler dependant thing.  If some of you
  90. >could compile and run my above code, maybe you could see if it occurs at the 
  91. >same point in the code as it did for me.  I am absolutely certain that it was
  92. >occuring where I indicated it was occuring (r3) because I spent hours on end
  93. >isolating it down to that exact spot.  Any insight would be appreciated.
  94. >I'm using xlC on IBM AIX.  I've also created a super simpified model of my 
  95. >project with actual filled in C++ code that I could email you if you'd like 
  96. >to take a look at it further.
  97.  
  98. >You might be looking at this program that I wrote and be wondering why the
  99. >hell I'm doing this pure virtual print function and calling it in the base
  100. >class friend operator<<  This is actually a very useful technique for
  101. >creating what amounts to a "virtual operator <<"
  102.  
  103. >Thanks in advance,
  104.  
  105. >-Mike
  106.  
  107.  
  108.  
  109.